home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.compilers / comp.sys.amiga.programmer_21070_000003.msg < prev    next >
Encoding:
Internet Message Format  |  1994-11-27  |  3.3 KB
  1. Path: etek.chalmers.se!chalmers.se!sunic!mcsun!Germany.EU.net!news.netmbx.de!mailgzrz.TU-Berlin.DE!math.fu-berlin.de!Sirius.dfn.de!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!rutgers!concert!sas!mozart.unx.sas.com!jamie
  2. From: jamie@cdevil.unx.sas.com (James Cooper)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: SAS/C 6.0: schelp crashes w/KS1.2
  5. Message-ID: <BwJ11M.5q5@unx.sas.com>
  6. Date: 22 Oct 92 14:17:45 GMT
  7. References: <1992Oct15.143152.7957@ugle.unit.no> <Bw82Fr.5H2@unx.sas.com> <1992Oct20.171858.7826@ugle.unit.no> <BwH38I.FGD@unx.sas.com> <1992Oct21.164539.26394@ida.liu.se>
  8. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  9. Organization: SAS Institute Inc.
  10. Lines: 50
  11. Originator: jamie@cdevil.unx.sas.com
  12. Nntp-Posting-Host: cdevil.unx.sas.com
  13.  
  14.  
  15. In article <1992Oct21.164539.26394@ida.liu.se>, micja@ida.liu.se (Michael Jansson) writes:
  16. >
  17. >In article <BwH38I.FGD@unx.sas.com>, walker@twix.unx.sas.com (Doug Walker) writes:
  18. >
  19. >> |> Changing the __stack variable doesn't seem to do anything to my stack size, according
  20. >> |> to Xoper. I always get the stack size I set in the shell. Is there anything special I
  21. >> |> should do?
  22. >>
  23. >> It's working.  Xoper reports the stack size and limits given in the Task structure for
  24. >> the task; when you specify __stack, you get a new stack allocated, but the Task
  25. >> structure fields are not modified.
  26. >
  27. >Is there a reason for that? I guess I role my own code with SwapStack (or was it
  28. >StackSwap :-) then, since programs with __stack will be slower otherwise. The
  29. >reason for that is that some functions in the OS checks for the size of the stack
  30. >of the caller. If the stack is too small or bogus (as with SAS) then they will
  31. >allocate a new stack, swap it in, and then de-allocate it when finished. This
  32. >takes time, especially the de-allocation. The same thing goes for other resident
  33. >libraries that are written in a sensible way, i.e. check the stack of the caller.
  34.  
  35. Yes, there's a reason.  StackSwap() doesn't exist prior to 2.0, so we'ld
  36. have to special case it (since there are a lot of 1.3 users still out
  37. there), which would make your code bigger, and people are always yelling
  38. when their programs come out bigger...  :-\
  39.  
  40. Also, if I remember correctly, the system libraries check the amount of
  41. stack *left*, not the amount total.  This means they should use the
  42. stack already in place in the task structure, since we won't have put
  43. anything at all on it... the only thing that will be there is whatever
  44. the system puts in place at process startup time.
  45.  
  46. Besides, this doesn't always happen!  We check the amount of stack the
  47. task already has allocated, and if that amount is >= the value in the
  48. __stack variable, we don't allocate a new stack, we just let it use the
  49. current one, just like it always did.
  50.  
  51. __stack is both a safety feature and a documentation saver.  For safety,
  52. it makes sure your code has a big enough stack, no matter what size the
  53. user has set in his shell, and you no longer have to document a stack
  54. size to set, since the startup code will allocate it for you if the user
  55. didn't set enough beforehand.
  56.  
  57. -- 
  58. ---------------
  59. Jim Cooper
  60. (jamie@unx.sas.com)                             bix: jcooper
  61.  
  62. Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
  63. and not necessarily those of my employer.
  64.